Mocks aren't stubs

martinfowler.com/articles/mocksArentStubs.html

상태 기반 테스트의 단점은 테스트 픽스쳐가 너무 번잡해진다는 점이고, 인터랙션 기반 테스트의 단점은 테스트 코드와 프러덕션 코드 사이의 커플링이 지나치게 강해진다는 점. 마틴 파울러 자신은 State-based test를 선호한다고.

Test double의 다양한 종류

Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined five particular kinds of double:

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in-memory database is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
• Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
• Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Of these kinds of doubles, only mocks insist upon behavior verification.

Classical and Mockist Testing

The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn’t really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service. …

An important offshoot of the mockist style is that of Behavior-driven development.